Re: bugtraq-digest V1 #68
Ronan David EPSHOM/INF (david@shom.fr)
Mon, 12 Dec 1994 13:48:28 +0100 (MET)
According to owner-bugtraq-digest@fc.net :
>
>
> bugtraq-digest Sunday, 11 December 1994 Volume 01 : Number 068
>
>
> ----------------------------------------------------------------------
>
> From: soulet@ecume.cict.fr (Gilles SOULET)
> Date: Fri, 9 Dec 1994 10:27:43 +0100 (MET)
> Subject: SunOS's xterm pb : again !
>
> I sent a message on this list few days ago, and I didn't noticed
> any real discussion about it. Since I wonder if this topic
> is still valid (or completly out of date :-), here's what
> I was talking about :
>
> Using Sun's Openwin under SunOS4.1.3, I noticed that the
> /usr/openwin/bin/xterm wasn't setuid ROOT. It seems to be a
> good thing (remember the "xterm -lf" + file link bug ?).
>
> When you launch an xterm, the system attachs a device to the
> xterm's shell. You can see this device by typing 'tty' in the xterm's
> window. OK.
>
> The pb is : Under SunOS, the terminal devices (/dev/ttyp?) are
> owned by root, with rights rw-rw-rw-. When you log on the machine,
> the login process changes the owner of the terminal, so the tty
> belongs to you, with minimum access rights. BUT when using an xterm,
> you don't have the permissions to change the owner and access rights
> of the newly allocated tty. So the device stays owned by root,
> WORLD READABLE and WORLD WRITEABLE !!!
>
> I think this introduces a major security hole, since everybody
> can read on a xterm's shell terminal device to get secret
> informations, including a password ! You can try this by using
> the "cat" command redirected from (or to) an xterm terminal device :
> it works !
>
> So what ?
>
> # Gillus
> ~~~~~~~~~~
>
> ------------------------------
>
> From: mc213012@ci.uminho.pt (Tiago Faro Lima Pedroso)
> Date: Fri, 9 Dec 1994 11:31:26 +0100 (MET)
> Subject: unsubcribe
>
> unsubscribe mc213012@ci.uminho.pt
>
> ------------------------------
>
> From: Justin Mason <jmason@iona.ie>
> Date: Fri, 09 Dec 1994 12:49:22 +0000
> Subject: 8lgm's SCO "at" hole
>
> [8lgm]-Advisory-10-EXPLOIT describes a hole where a setgid program runs
> /bin/pwd with popen(3).
>
> In case you don't know, this is the way that SunOS, as well as SCO,
> performs the getcwd() call. Other versions of UNIX may also implement
> it this way, although Solaris' getwd() doesn't (sorry folks -- don't
> have enough UNIX machines with trace commands!).
>
> trace/truss -f this C code to check:
>
> #include <stdio.h>
> main () { char x[1024]; getcwd(x, 1024); printf ("%s", x); }
>
> If you see a fork or vfork, your getcwd runs /bin/pwd.
>
> If you have any setuid programs that call getcwd(), make sure they
> sanitise their environment beforehand. Another thing to watch out
> for...
>
> - --j.
>
> ------------------------------
>
> From: roessler@indi5.iam.uni-bonn.de (Thomas Roessler)
> Date: Fri, 9 Dec 94 17:45:49 +0100
> Subject: Re: Race conditions
>
> > From: Christopher Samuel <chris@rivers.dra.hmg.gb>
> > Sender: bugtraq-owner@fc.net
> >
> > I've just checked this out with a noddy program and built the
> > following table up (appended at the end of this post along with the
> > program). The most suprising part of this exercise for me was that I
> > could only find *one* OS that failed the check and created the file
> > pointed to be the symlink! Must be the pessimist in me.. :)
> >
> > Notes:
> >
> > 1) The program was run as a normal user, not root.
> > 2) The ls output looks like:
> >
> > -rw-r--r-- 1 chris cs2 359 Dec 8 13:46 tst.c
> > lrwxrwxrwx 1 chris cs2 3 Dec 8 14:49 symlink -> ./a
> > -rwxr-xr-x 1 chris cs2 5492 Dec 8 14:50 tst*
> >
> >
> > Happy hunting, folks!
> > Chris
> > --
> > Christopher Samuel Phone: +44 1684 894644 chris@rivers.dra.hmg.gb
> > N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
> > postmaster@rivers.dra.hmg.gb usenet@rivers.dra.hmg.gb
> >
> > ----------------------------------------------------------
> > BAD - creates file with "open succeded (fh=3)":
> >
> > HP-UX V7.05
> > ----------------------------------------------------------
> > OK - fails with "open: File exists"
> >
> > Ultrix 4.4
> > Ultrix 4.2
> > SunOS 4.1.3_U1
> > SunOS 4.1.3
> > SunOS 4.1.1
> > Solaris 2.1
> > Solaris 2.3
> > USL SVR4.2
> > Unixware 1.1.2
> > SCO 3.2 (ODT3)
> > Irix 5.2
> > HP-UX 9.05
> > NeXTstep 3.2
> > DRS/NX 6000 SVR4 Version 7 Level 2 Increment 2
> > Linux 1.1.64
>
> Well, irix 4.0.5f behaves bad and creates the file.
>
> Cheers,
>
> Thomas
> - --
> Student at Institute for Applied Mathematics, University of Bonn * Snail
> mail: Thomas Roessler, Neheimer Weg 1, 51109 Koeln, Germany * INTERNET:
> roessler@indi5.iam.uni-bonn.de * BITNET: uzs076 at dbnrhrz1.bitnet * PGP
> public key info via finger * http://rhein.iam.uni-bonn.de:1025/~roessler
>
> If you can't convince them, confuse them.
>
>
> ------------------------------
>
> From: Christopher Samuel <chris@rivers.dra.hmg.gb>
> Date: Fri, 09 Dec 1994 18:47:47 +0000
> Subject: Re: Race conditions
>
> In message <9412090137.AA03311@muggy.gg.caltech.edu>,
> Walker Aumann <walkera@druggist.gg.caltech.edu> writes:
>
> > More datapoints on this symlink problem:
> > > ----------------------------------------------------------
> > > BAD - creates file with "open succeded (fh=3)":
> > >
> > > HP-UX V7.05
> > HP-UX 8.00
>
> thanks!
>
> > > ----------------------------------------------------------
> > > OK - fails with "open: File exists"
> >
> > HP-UX V9.05
> AIX 3.2.3e
> AIX 3.2.5
> DEC-OSF/1 3.0
>
> (I missed them first time around)
>
> The full list is in
> ftp://ftp.dra.hmg.gb/pub/TenDRA/staff/chris/symlinks-problem-list
>
> - --
> Christopher Samuel Phone: +44 1684 894644 chris@rivers.dra.hmg.gb
> N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
> postmaster@rivers.dra.hmg.gb usenet@rivers.dra.hmg.gb
>
> ------------------------------
>
> From: rwing!pat@ole.cdac.com (Pat Myrto)
> Date: Fri, 9 Dec 94 7:50:36 PST
> Subject: Re: Race conditions
>
> "In the previous message, Jason Matthews said..."
> >
> > On Wed, 7 Dec 1994, Michael Bresnahan wrote:
> >
> > > How does one code a suid program so that it evades these problems with
> > > symlink race conditions? Is there a way to atomically check if a file
> > > is a symlink and open it, or is there another stratedgy?
> >
> >
> > Simply do not use any temporary files...
> >
>
> And if a temp file MUST be made, use the mkstemp() call to generate the
> name and open it. Mkstemp() atomically generates the tempname from the
> template, opens the file and returns a handle. As the manpage says,
> mkstemp() eliminates the race condition between testing if a file exists,
> and the opening of the tmp file. Like mktemp(), mkstemp() uses a
> template containing six X's, and modifies it in place. Unlike mktemp(),
> instead of returning a char * pointiong to the string passed to it,
> mkstemp() returns a file handle to a file open for reading and writing.
>
> I haven't tried it with a symlink pointing to a nonexistant file having
> the name mkstemp() will use initially ('a' and the PID) to
> see if mkstemp() will fail (or choose another letter, like 'b' in the
> tempname). That will be an interesting test when I get a few moments.
>
> > Jason
> >
> > ----------------------------------------------------------------------------
> > jason@dickory.sdsu.edu San Diego State University
> > jason@mentor.sdsu.edu College of Engineering
> > jason@BOOM.extern.ucsd.edu Electrical*Computer Engineering
> > ----------------------------------------------------------------------------
> > The following email address are no longer valid
> > odn@LoD.amaranth.com
> > ----------------------------------------------------------------------------
> >
> >
> >
> >
>
>
> - --
> pat@rwing [If all fails, try: rwing!pat@eskimo.com] Pat Myrto - Seattle WA
> "No one has the right to destroy another person's belief by demanding
> empirical evidence." -- Ann Landers, nationally syndicated advice columnist
> and Director at Handgun Control Inc.
>
> ------------------------------
>
> From: fred@nasirc.hq.nasa.gov (Fred Blonder)
> Date: Fri, 9 Dec 1994 15:19:52 -0500
> Subject: Re: Race conditions
>
> From: rwing!pat@ole.cdac.com (Pat Myrto)
>
> And if a temp file MUST be made, use the mkstemp()
> call to generate the name and open it. Mkstemp()
> atomically generates the tempname from the template,
> opens the file and returns a handle. As the manpage
> says, mkstemp() eliminates the race condition between
> testing if a file exists, and the opening of the tmp file.
>
> But 'mkstemp()' is in section 3 of the manual; it's a subroutine,
> not a system call, so how can it be 'atomic'?
>
> ------------------------------
>
> From: Karl Strickland <karl@bagpuss.demon.co.uk>
> Date: Fri, 9 Dec 1994 21:05:14 +0000 (GMT)
> Subject: Re: 8lgm's SCO "at" hole
>
> >
> > [8lgm]-Advisory-10-EXPLOIT describes a hole where a setgid program runs
> > /bin/pwd with popen(3).
> >
> > In case you don't know, this is the way that SunOS, as well as SCO,
> > performs the getcwd() call. Other versions of UNIX may also implement
> > it this way, although Solaris' getwd() doesn't (sorry folks -- don't
> > have enough UNIX machines with trace commands!).
> >
> > trace/truss -f this C code to check:
> >
> > #include <stdio.h>
> > main () { char x[1024]; getcwd(x, 1024); printf ("%s", x); }
> >
> > If you see a fork or vfork, your getcwd runs /bin/pwd.
> >
> > If you have any setuid programs that call getcwd(), make sure they
> > sanitise their environment beforehand. Another thing to watch out
> > for...
>
> AFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call.
> getcwd() is only provided for backwards compatibility; i suppose all new
> code should be using getwd(2).
> - ------------------------------------------+-----------------------------------
> Mailed using ELM on FreeBSD | Karl Strickland
> PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk
> |
>
> ------------------------------
>
> From: "Declan A. Rieb" <darieb@sandia.gov>
> Date: Fri, 9 Dec 1994 14:31:21 -0700 (MST)
> Subject: Re: Race condition
>
> The symlink file (./a) was successfully built under A/UX 3.0.2 using
> Christopher Samuel's "noddy" program.
>
> (p.s. "noddy" means what in 'merkun, please?)
>
> Declan A. Rieb darieb@sandia.gov
> Sandia National Laboratories, Albuquerque NM 87185-0815
> Voice & FAX: (505) 845-8515
>
>
> ------------------------------
>
> From: jim@Tadpole.COM
> Date: Fri, 9 Dec 1994 16:51:12 -0600
> Subject: source to tmpfs fix needed
>
> Remember that loadable module that included the tmpfs fix?
> Does anyone still have it sitting around? I lost my copy.
>
> Jim
>
> ------------------------------
>
> From: mingus@summit.novell.com (Marcel-Franck Simon)
> Date: Fri, 9 Dec 1994 14:55 EST
> Subject: Novell security advisory on sadc, urestore and the suid_exec feature
>
> I am posting this on behalf of Novell Technical Support. Please contact
> them directly if you have any questions; if you must reply to me, I
> will forward.
>
> =======================================================================
>
> Recently, there were three security advisories posted on the
> "net" associated with several versions of the Unix Operating System.
> These advisories are related to the following:
>
> /usr/lib/sa/sadc The command is sgid-on-exec to "sys"
>
> /usr/sbin/urestore The command is suid-on-exec to "root"
>
> suid_exec feature This pertains to "ksh".
>
> One of the operating system versions affected was the UnixWare 1.1
> product distributed by Novell, Inc. Listed below are the results of
> the investigation that took place concerning the affected binaries:
>
> With respect to the "sadc" problem, the "sadc" binary in the
> UnixWare 1.1 product has been modified such that it no longer
> poses a security threat.
>
> This modification is provided as PTF683 and is available from
> Novell Technical Support at (800) 486-4835.
>
> With respect to the "urestore" problem, this requires an attribute
> modification to remove the suid-on-exec bit. The functionality of
> "urestore" should remain unchanged. This modification is also
> included in PTF683.
>
> The last advisory, suid_exec for ksh, does not apply to the version
> of "ksh" supplied with the UnixWare 1.1 product.
>
> This advisory relates to a feature in "ksh" that allows for the
> execution of suid-on-exec shell scripts. Since the UnixWare 1.1
> product provides this capability in the exec(2) system call in
> the kernel, the UnixWare 1.1 product does not need to set that
> DEFINE value when compiling "ksh" to achieve this capability and
> hasn't since SVR4.0.
>
> Novell, Inc. has sent source fixes to all SVR4.0, SVR4.2, and SVR4.2MP
> OEM customers for both the "sadc" and "urestore" advisories. These vendors
> should be making them available to licensees of their SVR4.X-based operating
> systems. If you are using any of the versions mentioned above, you should
> contact the appropriate vendor to obtain their official update.
>
> ------------------------------
>
> From: Steinar Haug <Steinar.Haug@runit.sintef.no>
> Date: Sat, 10 Dec 1994 08:30:48 +0100 (MET)
> Subject: Re: 8lgm's SCO "at" hole
>
> > AFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call.
> > getcwd() is only provided for backwards compatibility; i suppose all new
> > code should be using getwd(2).
>
> In SunOS 4.1.3 (and 4.1.2) they are both library functions. getcwd() uses
> popen, as noted. getwd() traverses the path upwards by repeatedly opening
> the directory on the level above and reading directory entries until it
> gets a match for the current directory. It uses /etc/mtab to avoid hanging
> across mount points that might be dead.
>
> In HP-UX 9.05 getcwd() traverses the path upwards - it does *not* use
> popen(). getwd() doesn't exist.
>
> POSIX wants you to use getcwd().
>
> Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
> Email: Steinar.Haug@runit.sintef.no
>
> ------------------------------
>
> From: rwing!pat@ole.cdac.com (Pat Myrto)
> Date: Fri, 9 Dec 94 23:32:20 PST
> Subject: Re: Race conditions
>
> "In the previous message, Fred Blonder said..."
> >
> > From: rwing!pat@ole.cdac.com (Pat Myrto)
> >
> > And if a temp file MUST be made, use the mkstemp()
> > call to generate the name and open it. Mkstemp()
> > atomically generates the tempname from the template,
> > opens the file and returns a handle. As the manpage
> > says, mkstemp() eliminates the race condition between
> > testing if a file exists, and the opening of the tmp file.
> >
> > But 'mkstemp()' is in section 3 of the manual; it's a subroutine,
> > not a system call, so how can it be 'atomic'?
> >
>
> I err'd, I was told by another it was atomic. After a bit more research
> stimulated by your response, I found out that what it does is something
> like mktemp() to generate an INITIAL tempname, and then tries an open(foo,
> O_EXCL|O_CREAT|O_RDWR, 0600) on the name (which will fail if a symlink
> or another file is there). If the open fails, the 'a' preceeding the
> pid in the tempname that was generated to replace the 6 'X's, gets
> incremented, and it tries again (with a 'b', 'c', ... prefix) until it
> succeeds or until the letter prefix has passed 'z'. There is no stat(),
> lstat(), or fstat() used -- the tempname is created (assuming pid ==
> 12345) with the leading letter 'a' as in a12345, and repeated open()s
> will try b12345, c12345, etc. If it cannot find a name to use, it will
> finally return with a value of -1 instead of a file handle.
>
> In other words, apparantly the 'atomicity' I was advised about is in
> the open() call with those options, and used in that way, in its behavior
> if a file exists, and then changing the name and re-trying again atomically
> if a file or symlink is seen. Sort of a trial-and-error scheme to find
> an unused name, selecting a different filename if anything exists by
> that name.
>
> Mkstemp tries to find the name, finding one that is unique at the time
> it creates it, hands it to the caller, then the caller calls open() on
> the not-necessarily-unique name some time later. In other words, the
> test for uniquness on the name actually used is NOT done in the open call.
> Mktemp() says the name is unique as of some nonzero time previously...
>
> In other words, mkstemp() is useful IFF open(x,O_CREAT|O_EXCL|O_whatever,mode)
> works properly. So, if the OS does NOT support O_EXCL or if it does NOT
> fail on an open O_RDRW call on a symlink pointing to nothing, one is back
> to square one.
> - --
> pat@rwing [If all fails, try: rwing!pat@eskimo.com] Pat Myrto - Seattle WA
> "No one has the right to destroy another person's belief by demanding
> empirical evidence." -- Ann Landers, nationally syndicated advice columnist
> and Director at Handgun Control Inc.
>
> ------------------------------
>
> From: Casper Dik <casper@fwi.uva.nl>
> Date: Sat, 10 Dec 1994 14:22:16 +0100
> Subject: Re: 8lgm's SCO "at" hole
>
> >AFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call.
> >getcwd() is only provided for backwards compatibility; i suppose all new
> >code should be using getwd(2).
>
> Neither of the calls is a system call on any system that I'm aware of.
> Getcwd(3) is the thing POSIX wants you to use.
> Getwd() is to getcwd() what gets() is to fgets() [ well, almost ].
>
> When chosing between: getwd(char *buf) and getcwd(char *buf, size_t size_of_buf)
> the choice should be obvious.
>
> In SunOS 4.1.x, getcwd() does call /bin/pwd.
> In Solaris 2.x, getcwd() use /etc/mnttab and some tree traversal
> to find the current directory. getwd is relegated to libucb.so and
> just calls getcwd(buf, MAXPATHLEN);
>
> Casper
>
> ------------------------------
>
> From: Karl Strickland <karl@bagpuss.demon.co.uk>
> Date: Sat, 10 Dec 1994 13:51:29 +0000 (GMT)
> Subject: Re: 8lgm's SCO "at" hole
>
> >
> >
> > >AFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call.
> > >getcwd() is only provided for backwards compatibility; i suppose all new
> > >code should be using getwd(2).
> >
> >
> > Neither of the calls is a system call on any system that I'm aware of.
>
> You're quite right - I stand corrected..
>
> > Getcwd(3) is the thing POSIX wants you to use.
> > Getwd() is to getcwd() what gets() is to fgets() [ well, almost ].
> >
> > When chosing between: getwd(char *buf) and getcwd(char *buf, size_t size_of_buf)
> > the choice should be obvious.
>
> I'm not so sure its as obvious as the choice between gets() & fgets().
> eg: from SunOS 4.1.x getcwd() man page:
>
> BUGS
> Since this function uses popen() to create a pipe to the pwd
> command, it is slower than getwd() and gives poorer error
> diagnostics. getcwd() is provided only for compatibility
> with other UNIX operating systems.
>
> So - for me at least - getwd() would be the obvious choice here. getwd()
> isnt quite as bad as gets() - at least there is an upper bound on getwd()
> (according to the documentation anyway, obviously not seen the src) of
> MAXPATHLEN bytes.
>
> > In SunOS 4.1.x, getcwd() does call /bin/pwd.
> > In Solaris 2.x, getcwd() use /etc/mnttab and some tree traversal
> > to find the current directory. getwd is relegated to libucb.so and
> > just calls getcwd(buf, MAXPATHLEN);
>
> Whats getwd() in Solaris 2.x? Does it just do getcwd(pathname, MAXPATHLEN) ?
>
> Cheers
> - ------------------------------------------+-----------------------------------
> Mailed using ELM on FreeBSD | Karl Strickland
> PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk
> |
>
> ------------------------------
>
> From: John Nemeth <jnemeth@cue.bc.ca>
> Date: Sat, 10 Dec 1994 17:23:52 -0800
> Subject: Re: 8lgm's SCO "at" hole
>
> On Dec 10, 2:22pm, Casper Dik wrote:
> } Subject: Re: 8lgm's SCO "at" hole
> }
> } Getwd() is to getcwd() what gets() is to fgets() [ well, almost ].
> }
> } When chosing between: getwd(char *buf) and getcwd(char *buf, size_t
> } size_of_buf) the choice should be obvious.
>
> I would have to disagree. fgets() can return any amount of data
> (potentially GB if connected to a socket or very large file); whereas,
> getwd() won't return anything bigger then MAXPATHLEN, so buf can be
> sized appropriately.
>
> }-- End of excerpt from Casper Dik
>
> ------------------------------
>
> From: "Jonathan M. Bresler" <jmb@kryten.Atinc.COM>
> Date: Sat, 10 Dec 1994 20:26:17 -0500 (EST)
> Subject: Re: Race conditions, mkstemp
>
> here is the source for mkstemp from csrg. note the filesystem
> must support exclusive file locking atomic to the open() for this to be
> helpful. as is written in the mkstemp() man page.
>
> why wasnt O_TRUNC included. that would hammer both soft and hard links
>
>
> Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc.
> | 2341 Jeff Davis Hwy
> play go. | Arlington, VA 22202
> ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346
>
> /*
> * Copyright (c) 1987 Regents of the University of California.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in the
> * documentation and/or other materials provided with the distribution.
> * 3. All advertising materials mentioning features or use of this software
> * must display the following acknowledgement:
> * This product includes software developed by the University of
> * California, Berkeley and its contributors.
> * 4. Neither the name of the University nor the names of its contributors
> * may be used to endorse or promote products derived from this software
> * without specific prior written permission.
> *
> * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> */
>
> #if defined(LIBC_SCCS) && !defined(lint)
> static char sccsid[] = "@(#)mktemp.c 5.10 (Berkeley) 2/24/91";
> #endif /* LIBC_SCCS and not lint */
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <errno.h>
> #include <stdio.h>
>
> static int _gettemp();
>
> mkstemp(path)
> char *path;
> {
> int fd;
>
> return (_gettemp(path, &fd) ? fd : -1);
> }
>
> char *
> mktemp(path)
> char *path;
> {
> return(_gettemp(path, (int *)NULL) ? path : (char *)NULL);
> }
>
> static
> _gettemp(path, doopen)
> char *path;
> register int *doopen;
> {
> extern int errno;
> register char *start, *trv;
> struct stat sbuf;
> u_int pid;
>
> pid = getpid();
> for (trv = path; *trv; ++trv); /* extra X's get set to 0's */
> while (*--trv == 'X') {
> *trv = (pid % 10) + '0';
> pid /= 10;
> }
>
> /*
> * check the target directory; if you have six X's and it
> * doesn't exist this runs for a *very* long time.
> */
> for (start = trv + 1;; --trv) {
> if (trv <= path)
> break;
> if (*trv == '/') {
> *trv = '\0';
> if (stat(path, &sbuf))
> return(0);
> if (!S_ISDIR(sbuf.st_mode)) {
> errno = ENOTDIR;
> return(0);
> }
> *trv = '/';
> break;
> }
> }
>
> for (;;) {
> if (doopen) {
> if ((*doopen =
> open(path, O_CREAT|O_EXCL|O_RDWR, 0600)) >= 0)
> return(1);
> if (errno != EEXIST)
> return(0);
> }
> else if (stat(path, &sbuf))
> return(errno == ENOENT ? 1 : 0);
>
> /* tricky little algorithm for backward compatibility */
> for (trv = start;;) {
> if (!*trv)
> return(0);
> if (*trv == 'z')
> *trv++ = 'a';
> else {
> if (isdigit(*trv))
> *trv = 'a';
> else
> ++*trv;
> break;
> }
> }
> }
> /*NOTREACHED*/
> }
>
> ------------------------------
>
> From: Casper Dik <casper@fwi.uva.nl>
> Date: Sun, 11 Dec 1994 14:07:02 +0100
> Subject: Re: Race conditions, mkstemp
>
> >
> > here is the source for mkstemp from csrg. note the filesystem
> >must support exclusive file locking atomic to the open() for this to be
> >helpful. as is written in the mkstemp() man page.
> >
> > why wasnt O_TRUNC included. that would hammer both soft and hard links
>
> Because it serves no useful purpose. A file created with O_EXCL|O_CREAT
> will have 0 lenght. If the file needs to be truncated (O_TRUNC) it
> already exists, but i that case the open w/ O_CREATE|O_EXCL would fail.
>
> O_CREATE|O_TRUNC|O_EXCL makes no sense.
>
> Casper
>
> ------------------------------
>
> From: Casper Dik <casper@fwi.uva.nl>
> Date: Sun, 11 Dec 1994 14:15:47 +0100
> Subject: Re: 8lgm's SCO "at" hole
>
> >On Dec 10, 2:22pm, Casper Dik wrote:
> >} Subject: Re: 8lgm's SCO "at" hole
> >}
> >} Getwd() is to getcwd() what gets() is to fgets() [ well, almost ].
> >}
> >} When chosing between: getwd(char *buf) and getcwd(char *buf, size_t
> >} size_of_buf) the choice should be obvious.
> >
> > I would have to disagree. fgets() can return any amount of data
> >(potentially GB if connected to a socket or very large file); whereas,
> >getwd() won't return anything bigger then MAXPATHLEN, so buf can be
> >sized appropriately.
>
> Almost true, and definitely true for binaries that ship with the system.
> But lets pick a nit:
>
> What happens when some future version of Unix increases the MAXPATHLEN
> manifest constant?
>
> Your application has it compiled in as 1024 (current standard value),
> but the getwd() routine can return a longer pathname in future.
> getcwd() will never have such a problem.
>
> But agreed, getwd() is currently not a problem. Getcwd is the preferred
> interface anyway (on modern systems :-)
>
> I've only seen something like this break once, bonus points for who
> can tell why the following is wrong:
>
> select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout);
>
> Casper
>
> ------------------------------
>
> From: "Jonathan M. Bresler" <jmb@kryten.Atinc.COM>
> Date: Sun, 11 Dec 1994 12:20:29 -0500 (EST)
> Subject: Re: Race conditions, mkstemp (fwd)
>
> On Sun, 11 Dec 1994, Casper Dik wrote:
>
> >
> > >
> > > here is the source for mkstemp from csrg. note the filesystem
> > >must support exclusive file locking atomic to the open() for this to be
> > >helpful. as is written in the mkstemp() man page.
> > >
> > > why wasnt O_TRUNC included. that would hammer both soft and hard links
> >
> >
> > Because it serves no useful purpose. A file created with O_EXCL|O_CREAT
> > will have 0 lenght. If the file needs to be truncated (O_TRUNC) it
> > already exists, but i that case the open w/ O_CREATE|O_EXCL would fail.
> >
> > O_CREATE|O_TRUNC|O_EXCL makes no sense.
> >
> > Casper
> >
>
>
> i gotta learn to read the man pages more carefully. there it si
> at the bottom, in plain view:
>
> [EEXIST] O_CREAT and O_EXCL were specified and the file exists.
>
> sorry for wasting everyone's time.
> jmb
>
> Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc.
> | 2341 Jeff Davis Hwy
> play go. | Arlington, VA 22202
> ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346
>
>
>
>
>
> ------------------------------
>
> From: "Christopher A. Stewart" <stewart@networx.com>
> Date: Sun, 11 Dec 1994 15:14:35 +0800
> Subject: Re: 8lgm's SCO "at" hole
>
> >>>>> "Casper" == Casper Dik <casper@fwi.uva.nl> writes:
>
> [Stuff deleted]
>
> Casper> I've only seen something like this break once, bonus
> Casper> points for who can tell why the following is wrong:
>
> Casper> select(getdtablesize(), &readfds, &writefds,
> Casper> &exceptfds, &timeout);
>
> Casper> Casper
>
> Since RLIMIT_NOFILE is not a constant, if a program changes it between
> the formation of the fdsets and calling it could cause problems,
> mostly would, if RLIMIT_NOFILE was increased..
> - --
> - ----------------------------------------------------------------------
> Christopher A. Stewart | (Standard disclaimers are in effect)
> System/Network Administrator |
> Legent Corp. Networx Div. |
> Bellevue, Wa. 98004 |
> Voice (206)-688-2154 |
> Fax (206)-688-2050 |
>
> ------------------------------
>
> End of bugtraq-digest V1 #68
> ****************************
>
>